MHQuake Source Code Readme
==========================

This source code is in the process of being stripped to the bone.  All unnecessary legacy functions are being
removed, all non-GLQuake code is being removed, all PARANOID and IDGODS code is being removed.

A lot of stuff has been completely rewritten (see the Engine readme for why) and in time a lot more will be.

I've compiled all the assembly language files as a static library and linked that, so there's no longer any
need to mess around with that gas2masm thing, and you should be able to compile MHQuake successfully if you
don't have MASM.  The assembly language files and the gas2masm project are no longer being included in any
MHQuake release - basically because it doesn't use them!  The source code for them remains identical to ID's
released versions, if you want it.

Most includes have been removed from "quakedef.h" and added to only the files that need them.  If you want to
add any new functions and you get compile/linker errors, the most likely probability is that this is the
cause.  E.g. cldemo.c does not include glmodel.h, so any additions to that which require glmodel.h will fail.

I've compiled MHQuake using the February 2003 MS Platform SDK Headers and Libs, and the Direct-X 8.1 SDK
Headers and Libs.  It is no longer necessary to have the "DXSDK" folder with your source code, and in fact
MHQuake will fail to compile if you don't have "dxguid.lib" in one of your library file paths.  I'd distribute
the Direct-X 8.1 version of this with the code only I'm not too sure of Microsoft's policy on doing so.

MHQuake was built using MS Visual C++ 6.0 Enterprise with SP 5, on a Windows XP Pro box.  I've always found 
that compiling on an NT based platform resulted in a more stable finished product.  At some stage I may move
it over to Visual Studio .NET 2003 (it's a much nicer build environment), although this is low enough on the 
priority list.

Every released MHQuake executable is a fresh build (i.e. using "Rebuild All") so there is no incremental
linking, etc in the released executable.

There are certain coding conventions I grew up with and have come to like over the 15 odd years since I first
learned C - stuff to do with positioning of braces, tabs, spacing, etc.  In most cases where I've modified an
existing function I've first gone through it and adjusted it to what I find readable.

Sometimes I may do something in an unoptimised or clunky fashion.  This is normally because it's simpler.  I
like to be able to come back to my code after a few months and understand at a glance what it's doing.  If it
doesn't affect speed, so what?  (This is something that only experience can properly teach you...)

While I like the idea of C++, I do very strongly believe that low-level system code should be as direct as
possible.  It's a shame that people aren't taught proper procedural code anymore.  A programming language is
just a tool, like any other, and you don't use a hammer to cut a piece of wood, do you?
